 
             the "other" save-with-replace problem
 
everyone has heard (and been properly preached at, no doubt) about the dangers
of the save-with-replace option hereinafter referred to as save@) in commodore
dos.  whether or not there is really a dos "bug" in this command has been
argued ad nauseam in publications and on the various commodore forms as well.
i think this is more a matter of <belief> than anything else, and i do not
write to add (or detract, for that matter) anything from that longstanding
argument.  i am writing about an entirely different problem which can arise
from saving files, particularly program files, using the "save@" procedure.
--
after spending most of an evening working on a rather long program named
"cross" (actually a program designed for on screen composing and editing of
crossword puzzles, if any one is interested) and doing several saves of various
versions of the program (*not*, i might add, using save@), i was through
working on it and scratched all the old versions of the program, just to clean
up the diskette a bit.  then, since it wasn't time to go to bed yet, i decided
to work on another short program called "clues."  i made only a few changes in
it, and decided, for reasons best left for discussion another time, to use the
save@ procedure to save it, which i then did.  it was only after the drive
stopped whirring that i realized i had used the name "cross," rather than
"clues", to save@.  the old sinking feeling hit somewhere in my abdominal
region, and i could hear all those articles i've always read about backing up
data starting to repeat over and over again in my head.  now i had a copy of
the most recent version of "clues" on the diskette, misnamed as "cross."  the
*real* "cross" was, of course. . . gone.
--
well, "gone" is a kind of generic term for this file.   the file, i realized,
though, was still on the diskette, since i read somewhere that the save@
routine writes an entirely new copy of the file to the disk *before* it
deallocates the sectors of the old file.  it was not scratched, either, because
it was no longer listed in the directory, even with a file type byte of "$00."
now, through the mists of time, i prefer to call it, "more than scratched but
less than erased."  i'm sure at least one form of copy protection must use just
such files.
--
enough of the flowery prose.  presumably, if you are reading this, you may have
the same problem.  the rest of this article will be a more-or-less "cookbook"
recipe of how to recover such as file.  first, forget about any "file
unscratcher" programs you may have on your utilities disks.  this file has
*not* been scratched.  the directory entry which appears to refer to the file
you have lost refers in fact to another file which, for the moment at least, is
of no concern to you.
--
the general plan is that you will modify a directory enter on the disk so that
it refers to the lost file, which you then will be able to load normally and
save again under the correct name.  don't worry if you don't understand the
strategy -- tactics are to follow.
--
1.  take a deep breath.
2.  exhale.
3.  take the diskette out of the drive.
4.  put a write protect label on the disk.
    (don't remove this label until you have recovered your file and resaved it)
5.  make a backup of the disk.
--
(note 1:  for those of you unfamiliar with the word "backup" as used in this
sense, please note that this must be done with  a "disk backup," "whole disk
copier," "disk nibbler," or some such program that copies the disk block-for-
block, and *not* a "file copier," which merely reads the directory and copies
the files in it.  the file you want copied is *not* in the directory, so a file
copier will not do the trick.)
--
(note 2:  you will note i said "a" backup.  how many you make is up to you.  if
there are other programs on the diskette that you want to use, you will need
two backups, one to use, and one for file recovery.  if you mess up a backup in
the recovery process, you will need to make another.  you are *not* going to
recover the file from the original disk, but from a backup!!)
--
6.  put the original disk somewhere safe, preferably where you can't reach it
 
--
7.  there are only two pieces of information you need to recover your file:
the starting track and sector, and the length of the file.  you may not even
need the latter, but it is easy enough to get after you get the former.
--
8.  determining starting track and sector:  most programmers will have,
somewhere in their bag of tricks, a program known as a "disk doctor" or a "disk
editor."  it simply allows you to read an entire block from the diskette and
examine it, usually giving both hex numbers and ascii translation of the bytes
in that block.  ("sector" and "block" are synonymous.)
--
using such a program, read the first directory block (track 18, sector 1) and
just look at it for a minute.  don't change anything or do any "writing" to to
diskette at all.  the first two bytes show the next directory block -- ignore
them!  the third byte shows what type of file, ignore it for now too.  the
fourth and fifth bytes show the track and sector of the start of the file.  the
next 16 bytes show the name of the file -- again, ignore these.  the 31st and
32nd bytes (be careful, it's easy to mess up counting by hand on a computer
screen) show the number of blocks the file occupies.  this was just a geography
lesson; you're not going to change anything now.  remember, the directory entry
you were just examining belongs to the first file on the directory, not to your
lost file.
--
now you've got a search ahead of you.  you've got to find the first block
(sector) of your lost file.  how to do it is a matter of personal preference,
up to a point.  if you have plenty of time, you could search every single block
(over 600 of these little mothers).
--
before you go crazy, it is important to realize that the block you are looking
for is different in one particular way from most of the other blocks on the
diskette:  the third and fourth bytes of this block contain the "normal" load
address for a program file.  if it is a basic program, these two bytes will be
$01 and $08 ($0801 hex or 2049 decimal, the normal basic load address in the
c-64).  this helps quite a bit, for you can eliminate any block which doesn't
have these bytes as the third and fourth bytes.  you can search every block,
rejecting any that don't have these two bytes in those positions.
--
using your disk editor/doctor program, when you find a block that has the right
load address in the right position, you can try to read the ascii translation
and decide if this is your lost program or not.  unless you remember the
program pretty well, or have the name of the program in the first few lines, it
will be difficult to tell this way.  a better way is to use the disk
editor/doctor program to trace through the directory and write down a list of
all the "known" start of program blocks, then find the one on the list
generated by "flost.bin" than is not on your handwritten list.  this is the
one!!
--
9.  determine how many blocks your lost file is in length.  the hard way:
using your disk editor/doctor program, start with the first block (the one you
found above in #8) and keep going through the program and just count how many
blocks there are.  an easier way:  there are many programs which will chain
through a program and show the track and sector for each block and count them
up for you.
--
you now have the two pieces of information referred to earlier:  starting track
and sector, and file length.  you are almost home free!!
--
10.  using your disk editor/doctor program, again go to track 18, sector 1 (the
first sector of the directory and look at it.  the disk editor/doctor program
should have some way of letting you *change* bytes, as well as just look at
them.  they all work differently, but usually you will place the cursor over
the bytes you want changed and just type in the changes.
--
11.  if the third byte is already $82, forget this step.  otherwise, make is
$82 if your lost file is a program (see note at end if it is a sequential
file.)
--
12.  the fourth and fifth bytes now need to be changed to the track (fourth
byte) and sector (fifth byte) that you found in #8 above.  this must be done in
hexadecimal numbers (assuming your disk editor/doctor only allows this).
explaining hexadecimal is beyond the scope of this article.
--
13.  the 31st byte and 32nd byte will contain your file length in low byte-high
byte order.  if your file is not more than 255 blocks in length, you don't have
to understand what "low byte-high byte" means,  just put the number of blocks
in the 31st byte and zero ($00) in the second byte, again in hex.
--
14.  check again by counting (or get a small child to count) and make sure that
$82 is in the third byte (assuming your lost file is a program), the track
number on which your file starts is in the fourth byte, the sector on which it
starts is in the fifth byte, and the file length in the 31st and 32nd byte.
--
15.  do whatever your disk editor/doctor program requires to rewrite the
directory block to the diskette.
--
16.  unless you specifically and positively *know* that your disk editor/doctor
program validates the diskette after writing (it probably won't, since it
really only matters when you are changing the directory), validate the diskette
by entering the following in direct mode:
--
open15,8,15,"v0:" and hit <return>
--
17.  notice that you haven't changed the name of the first file in the
directory.  your lost file, on this backup disk, at least, now has the same
name as that file.  whatever that program was, it's gone.  that is one of the
reasons you used a backup disk in the first place.
--
18.  try to load the lost program.  list it and see if it's all there.  it
should be!!
--
19.  save the program to another diskette, just for safety.
--
20.  now, and only now, take the write protect label off your original disk.
save the lost program under a different name, and if your wish, scratch or
rename the bogus file you created when you used save@ in the first place.
--
wouldn't it have been easier just to backup the program in the first place or
just not use save@?
--
note on sequential files:  by the nature of their use, this type of problem is
not likely to happen with sequential files.  usually they are written under
program control, and even if open@ is used, file names are not likely to get
confused.  if it were to happen, however, the only difference in all this
process is that the file type (third byte of the directory block) must be $81
instead of $82 for a sequential file.  finding the starting block is easier in
some ways, especially if it is a text file, because the ascii will make more
sense, but you can't use the trick of eliminating blocks without the proper
load address, since this isn't a part of sequential files.
--
if you have any questions, please e-mail to 72167,3312.
--
rick joslin
i have written a program stored on cbmprg as "flost.bin", but really named
"lost file" which will greatly ease the pain of this process.  it should be
user-friendly enough to use from the menus provided, but there is a small doc
file called "flost.doc" which will give you instructions on how to use it if
needed.  for those few of you that have a b128 (not c), you need "flostb.bin".
